This invention relates to computer networks. More specifically, it relates to a method and system for address server redirection for multiple network address networks.
The Internet Protocol (xe2x80x9cIPxe2x80x9d) is an addressing protocol designed to facilitate the routing of traffic within a network or between networks. The Internet Protocol is used on many computer networks including the Internet, intranets and other networks. Current versions of Internet Protocol such as Internet Protocol version-4 (xe2x80x9cIPv4xe2x80x9d) are becoming obsolete because of limited address space. With a 32-bit address-field, it is possible to assign 232 different addresses, which is 4,294,967,296, or greater than 4 billion globally unique addresses.
However, with the explosive growth of the Internet and intranets, Internet Protocol addresses using a 32-bit address-field may soon be exhausted. Internet Protocol version-6 (xe2x80x9cIPv6xe2x80x9d) proposes the use of a 128-bit address-field for Internet Protocol addresses. However, a large number of legacy networks including a large number of Internet subnets will still be using older versions for Internet Protocol with a 32-bit address space for many years to come. As is known in the art, a subnet is smaller of part of a larger network using a similar network addressing scheme.
Network Address Translation (xe2x80x9cNATxe2x80x9d) has been proposed to extend the lifetime of Internet Protocol version 4 by allowing subnets with private Internet Protocol addresses to exist behind a single or small number of globally unique Internet Protocol addresses (see e.g., Internet Engineering Task Force (xe2x80x9cIETFxe2x80x9d) RFC 2663, xe2x80x9cIP Network Address Translator (xe2x80x9cNATxe2x80x9d) Terminology and Considerations,xe2x80x9d by P. Srisuresh and M. Holdrege, August 1999). Each private host uses a single global Internet Protocol address is used for communication with external networks such as the Internet.
As is known in the art, the Internet Engineering Task Force (xe2x80x9cIETFxe2x80x9d) has assigned three sets of private Internet Protocol addresses: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The number after the xe2x80x9c/xe2x80x9d indicates a number of bits used as a private network identifier. For example, the xe2x80x9c/8xe2x80x9d indicates that the first eight bits are used as a private network identifier. A network address represented as xe2x80x9cnetwork address/n-network bitsxe2x80x9d indicates that the first n-network bits represent a network identifier. The number of bits remaining represent the number of available host network addresses. For example, if a total of 32 bits are used for a network address (e.g., 32-bits for IPv4 addresses) and a xe2x80x9cnetwork address/8xe2x80x9d notation is used, then 32xe2x88x928=24 bits remain for host network addresses. In this example at most 224 host network addresses are available. Thus, the three sets of private Internet Protocol addresses: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 include at most 224, 220, and 216 addresses respectively. A private network may use any of these addresses without consulting any official Internet administrative entity.
Internally, a subnet may use local private addressing. Local private addressing may be any addressing scheme that is different from the public Internet Protocol addressing. The local addresses on a subnet are not available to the external, global Internet. When a device or node using local addressing desires to communicate with the external world, its local address is translated to a common external Internet Protocol address used for communication with an external network by a network address translation device. That is, network address translation allows one or more global Internet Protocol addresses to be shared among a larger number of network devices using local private addresses.
There are several problems associated with using network address translation to extend the life of the Internet Protocol. Network address translation interferes with the end-to-end routing principal of the Internet that recommends that packets flow end-to-end between network devices without changing the contents of any packet along a transmission route (see e.g., xe2x80x9cRouting in the Internet,xe2x80x9d by C. Huitema, Prentice Hall, 1995, ISBN 0-131-321-927).
Current versions of network address translation replace a local network address in a data packet header with an external global network address on outbound traffic, and replace an external global network address in a data packet header with a local private network address on inbound traffic. This type of address translation is computationally expensive, causes security problems by preventing certain types of encryption from being used, or breaks a number of existing applications in a network that cannot coexist with network address translation (e.g., File Transfer Protocol (xe2x80x9cFTPxe2x80x9d)).
Current versions of network address translation may not gracefully scale beyond a small subnet containing a few dozen nodes or devices because of the computational and other resources required. Network address translation potentially requires support for many different application layer internal network protocols be specifically programmed into a translation mechanism such as a network address translation router.
Computational burdens placed on a network address translation router may be significant and degrade network performance, especially if several network address translation-enabled sub-networks share the same network address translation router. In a worst case scenario, a network address translation router translates every inbound and outbound data packet.
Some of the problems associated with network address translation of private network addresses into public network addresses have been overcome with Distributed Network Address Translation (xe2x80x9cDNATxe2x80x9d) described in co-pending applications Ser. No. 09/035,600, 09/270,967 and 09/271,025 assigned to the same Assignee as the present application. See also xe2x80x9cDistributed Network Address Translationxe2x80x9d, by Michael Borella, David Grabelsky, Ikhlaq Sidhu, and Brian Petry, IETF Internet Draft,  less than draft-borella-aatn-dnat-01.txt greater than , October 1998. Distributed Network Address Translation is also called xe2x80x9cRealm Specific Internet Protocolxe2x80x9d (xe2x80x9cRSIPxe2x80x9d) by the IETF. For more information on Realm Specific Internet Protocol see xe2x80x9cRealm Specific IP Framework,xe2x80x9d by M. Borella and J. Lo, IETF draft,  less than draft-ieft-nat-rsip-framework-02.txt greater than , October 1999, and xe2x80x9cRealm Specific IP: Protocol Specification,xe2x80x9d by M. Borella and J. Lo, IETF draft,  less than draft-ietf-nat-rsip-protocol-02.txt greater than , August 1999.
For the Distributed Network Address Translation methods described in the co-pending applications, network devices request a set of locally unique ports with a Distributed Network Address Translation Protocol called a xe2x80x9cPort Allocation Protocolxe2x80x9d (xe2x80x9cPAPxe2x80x9d) from a Distributed Network Address Translation server for external communications with a public network like the Internet. A network device on a private network replaces default or ephemeral ports (e.g., such as Transmission Control Protocol or User Datagram Protocol) with the locally unique ports. The network device uses a combination network address including a locally unique port and a common external network address (e.g., an IP address) for the Distributed Network Address Translation server for communications with the external networks. The network devices use private network addresses for local communications on the private network.
A Distributed Network Address Translation server maintains a port-to-private network address table as locally unique ports are allocated to network devices. Network devices send data packets to external networks using a combination network address including a locally unique port and the common external network address via the Distributed Network Address Translation server. For inbound data packets from an external network, the Distributed Network Address Translation server uses the port-to-private network address table to route data packets back to the appropriate network device on the private network.
It is becoming commonplace for private stub network or subnets to be xe2x80x9cmultiple address networks.xe2x80x9d Multiple address networks are networks in which more than one type of network address is used, or two or more addresses of the same type are used. For example, a subnet may use private Internet Protocol addresses for local communications and use public, globally routable Internet Protocol addresses for communications with external public Internet Protocol networks such as the Internet. As another example, a private subnet may use older 32-bit Internet Protocol version-4 addresses to communicate with external networks, and use the new 128-bit Internet Protocol version-6 addresses to communicate on a local subnet. Networks using Distributed Network Address Translation or Realm Specific Internet Protocol are also examples of multiple address networks.
A network device on a multiple address network needs to obtain at least two network addresses. A first network address is a primary network address used for local communications with other network devices on a private subnet and a secondary network address is a secondary network address used for remote communications on public networks like the Internet.
As is known in the art, Dynamic Host Configuration Protocol (xe2x80x9cDHCPxe2x80x9d) servers are often used to allocate primary Internet Protocol addresses and configuration parameters such as a netmask, a gateway router, a Domain Name Server (xe2x80x9cDNSxe2x80x9d) and other parameters for network devices on a private network. The Dynamic Host Configuration Protocol is used to dynamically allocate network addresses and dynamically obtain configuration parameters. If the Dynamic Host Configuration Protocol is not used, then network addresses and configuration parameters have to be statically assigned to network devices connected to a network. Static assignment of network address and configuration parameters limits the ability of a network device to move to a new network or a new subnet. The Dynamic Host Configuration Protocol allows a network device to dynamically broadcast a message to a Dynamic Host Configuration Protocol server whenever it moves to a new network or subnet requesting a network address and configuration parameters.
Another secondary protocol, such as a Distributed Network Address protocol (e.g., the xe2x80x9cPort Allocation Protocolxe2x80x9d) or a Realm Specific Internet Protocol may be used to allocate secondary network addresses or translation ports that are used to translate private or local Internet Protocol addresses into public, external Internet Protocol addresses.
However, there are several problems associated with allocating multiple addresses with multiple protocols for multiple address networks. One problem is that a subnet typically will use a Dynamic Host Configuration Protocol server to allocate primary Internet Protocol addresses and another server to allocate secondary network addresses, such as those allocated for Distributed Network Address Translation or Realm Specific Internet Protocol.
In many instances a network device requesting a primary and a secondary network address is on a different subnet than the primary network address server or the secondary network address server. The subnets are typically connected by a router. As is known in the art, a router translates differences between network protocols and routes data packets to an appropriate device on a network.
In most private networks, a router will relay Dynamic Host Configuration Protocol messages since this protocol is well known in the networking arts and most routers recognize Dynamic Host Configuration Protocol messages and implement a Dynamic Host Configuration Protocol layer. However, most routers do not recognize secondary network address request messages without changes to the router software. Thus, a network device can request a primary network address, but may have trouble requesting a secondary network address from a secondary network address server.
There have been a number of proposed solutions to this problem. First, a subnet could require that every network device connected to the subnet use a configuration file that includes the address of a designated secondary network address server. However, this would require explicit configuration of each network device. For mobile network devices such as laptop computers and personal digital assistants that may be attached to many different subnets, multiple configuration files may have to be maintained. This places an unacceptable burden on network administrator""s and makes it difficult for a user to ensure the proper configuration file is used on the proper subnet.
Another solution is to require that a protocol used to request secondary network addresses use BOOT strap Protocol (xe2x80x9cBOOTPxe2x80x9d) ports. As is known in the art, BOOTP is a protocol used to initialize and boot network devices on a network. The format of Dynamic Host Configuration Protocol messages is based on the format of BOOTP messages. The Dynamic Host Configuration protocol is typically considered an extension of the BOOTP protocol. Using BOOTP ports would allow Dynamic Host Configuration Protocol-like stateless configuration and message relaying of secondary network address protocols in a router. However, this solution causes potentially serious interoperability issues. For example, network devices, the Dynamic Host Configuration Protocol server and a secondary network address server may contend for the same BOOTP ports at the same time causing collisions, confusion and other network problems. In addition, a secondary address server message broadcast to a BOOTP port on another subnet may not be forwarded by a router to the subnet.
Another solution is to define a secondary network address protocol router relay function for routers on a subnet. This solution would also allow Dynamic Host Configuration Protocol-like stateless configuration and message relaying for secondary network address protocols in the router. However, this would require modifications to the software, firmware and/or hardware on a huge installed based of routers from various manufacturers. This solution would expensive and require the cooperation of a number of number of network owners and router manufacturers, and thus is not feasible given the large amount of routers used in today""s networks.
Thus, it is desirable to provide a solution to the problem of allocating multiple types of network addresses for multiple address networks. The solution should allow existing Dynamic Host Configuration Protocol servers and secondary network address servers to be reached via routers without any changes to any existing routers in existing networks.
In accordance with preferred embodiments of the present invention, some of the problems associated with allocating multiple addresses with multiple protocols for multiple address networks overcome. A method and system for address server redirect for multiple address networks is provided.
One aspect of the invention includes a method for address server redirect from a client network device. The method includes requesting a primary network address and an address of a secondary network address server from a primary network address server. The address of the secondary network address server is requested in an option field in a message sent to the primary network address server to request a primary network address. The primary network address is used by a network device to communicate with other network devices on a first network. The secondary network address is used by the network device to communicate with other network devices on a second network. A message used to request a primary and a secondary network addresses may travel through one or more routers on the first network.
Another aspect of the invention includes a method for address server redirect from a network address server. A primary network address server allocates a primary network address to a network device. The primary network address server also conducts a test to determine if the network device is requesting an address of a secondary network address server in an option field of a message used to request the primary network address. If the network device is requesting an address of a secondary network address server in an option field, the primary network address server selects an address of a secondary network address server from a table. The secondary network address is returned to the network device in a same message as a primary network address.
Another aspect of the invention includes a system for address server redirect. The system includes a primary network address server, a secondary network address server and a client network device. The primary network address server is used for allocating a primary network address and for supplying a network address of a secondary network address server. The primary network address is used by a network device to communicate with other network devices on a first network. The secondary network address server is used to request a secondary network address that is used by a network device to communicate with other network devices on a second network. The client network device is used for communicating with other network devices on a first network using a primary network address allocated by the primary network address server and for communicating with other network devices on a second network using a secondary network address allocated by the secondary network address server.
For example, in one exemplary preferred embodiment of the present invention, the primary network address is a private Internet Protocol address and the secondary network address is a public Internet Protocol address. In another exemplary preferred embodiment of the present invention, the primary network address is an Internet Protocol version-6 address and the secondary network address is an Internet Protocol version-4 address.
In one exemplary preferred embodiment of the present invention, the primary Internet Protocol address is allocated by a Dynamic Host Configuration Protocol server and the secondary network address is allocated by a Distributed Network Address Translation protocol or a Realm Specific Internet Protocol server. The method and system may further allow the BOOTP relay function of existing routers to be used for Dynamic Host Configuration Protocol messages including a request for a network address for a secondary network address server. Thus, a secondary network address server can use virtually any application protocol and virtually any port number for communications without having to be on a same subnet as network device clients.
However, the present invention is not limited to such exemplary embodiments, and the present invention can be used to acquire virtually any type of primary network addresses and secondary network address from virtually any type of primary network address server or secondary network address servers.
The method and system of the present invention may allow allocating multiple types of network addresses for multiple address networks. The method and system may also allow existing primary network address servers and new secondary network address servers to be reached via routers without any changes to any existing routers in existing networks.
The foregoing and other features and advantages of a preferred embodiment of the present invention will be more readily apparent from the following detailed description. The detailed description proceeds with references to the accompanying drawings.